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L'invention concerne un dispositif et un procede permettant de 
5 transmettre des informations entre deux couches d'une pile reseau. 

Elle s'applique dans le domaine des transmissions avec pertes 
dues au medium de transmission (ex : transmissions sans fil). Elle s'applique 
dans tout systeme de transmission de donnees comportant un mecanisme 
de compression et/ou de decompression d'en-tete. 

10 

La transmission de texte, d'images et de video par I'intermediaire 
de canaux de largeur de bande limitee peut etre affectee de maniere 
importante par des erreurs dues au canal. De tels systemes utilisent 
traditionnellement des codeurs de source pour reduire la redondance des . 
15 sympoles sources et reduire ainsi la quantite d'information a transmettre,-. 
puis des codeurs correcteur d'erreur (ou de canal) pour augmenter la - 
robustesse de reformation transmise sur le canal. Ceci est classiquement ■? 
realise grace aux standards de compression des codes de longueur variable. .-. 
(VLC : codes d'Huffman, codes arithmetiques,..) et au codage de canal, a la:; 
20 modulation (ensemble d^signe dans la suite sous le terme gSnerique de 
« codeur/decodeur de canal ») pour augmenter la robustesse de la 
transmission sur le canal. Une optimisation plus integree peut etre obtenue 
en developpant une strat^gie de codage/d6codage conjoint source-canal. Le 
point clef consiste alors a utiliser de maniere approprtee la redondance de la 
25 source residuelle pour la partie decodage. Cette redondance peut etre 
consideree comme une forme de protection de canal implicite par le 
decodeur et etre exploitee de fapon a offrir une capacite de correction 
d'erreur. 

Dans les systemes simples ou le codeur de source 1 et le codeur 
30 de canal 2 (respectivement le decodeur de source 3 et le decodeur de canal 
4) sont directement interfaces, les techniques de codage conjoint source- 
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canal peuvent etre implements facilement en echangeant Clnformatlon 
entre les differents blocs, comme le montre la figure 1. La reference 5 
designe le canal de transmission. 

Du cote emetteur, les donnees d'information sur la sensible de la 
source aux erreurs canal (Source Significance Information ou SSI) peuvent 
etre transmises du codeur de source au codeur de canal afin de permettre 
Implication des techniques telles que la protection inegale aux erreurs 
(Unequal Error Protection ou UEP). De facon a adapter les taux de codage 
de source et de codage de canal aux conditions du canal de propagation il 
est aussi utile de fournir Information relative a I'etat du canal (Channel State 
Information ou CSI) au codeur de source et au codeur de canal. Dans le 
doma,ne des communications numeriques, les methodes traditionnelles de 
decodage. appliquees a de tels schemas concatene*. qui permettent des 
gams de codage eleves avec une complete raisonnable et une robustesse 
aux erreurs de transmission, peuvent etre a decisions « dures » (hard) ou a 
decisions « souples » (soft) ou « ponderees » selon que le signal est binaire 
ou analogique. 

Les methodes de decodage a decisions souples permettent 
damehorer asymptotiquement la performance, en terme d'erreur de 
Plusieurs decibels sur la plupart des canaux. ^information souple apparalt 
done comme necessaire dans le domaine des communications modernes 
Afin de permettre le decodage souple, le decodeur interne doit fournir une 
sortie souple au decodeur externe et vice-versa dans le cas d'un decodage 
rterafif. En consequence, du cote receptee, les sorties souples du canal et 
Information CSI relative a la fois a I'amplitude de Tevanouissement et au 
bruit, peuvent etre fournies par le canal au decodeur de canal qui realisera le 
decodage de canal a entree et sortie souples (Soft Input Soft Output ou 

Par ailleurs, la sortie souple du decodeur de canal ou information 
de fiabilite du decodeur (Decoder Reliability Information ou DRI) seront 
transmises au decodeur de source qui realisera le decodage de source a 
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entrees souple et fournira une sortie souple pour les informations de source, 
c'est — a-dire Pinformation a posteriori de la source (Source A posteriori 
information ou SAI) peut etre retransmise au decodeur de canal pour 
effectuer le decodage de canal controle par la source et eventuellement le 
5 decodage iteratif source-canal. 

Toutefois, les codeurs/decodeurs de source et de canal sont 
souvent des dispositifs appartenant a un reseau qui ne peuvent pas 
echanger ^information a cause des couches protocolaires 6 qui les 
separent, comme il est illustre a la figure 2. 
10 Les diverses informations a ^changer entre les d6codeurs doivent 

passer a travers differents niveaux de protocoles r6seau. Toutefois, pour 
rester compatibles avec les recommandations et les implementations [1], de 
telles transmissions ne doivent pas interferer avec I'utilisation reguliere du 
reseau. Ceci implique que reformation supplemental soit transmise de 
15 fagon transparente pour la pile protocolaire. 
Modele de la couche OSI 

En pratique, le transfert des informations DRI et SAI entre le 
codeur de source et le codeur de canal consistera a transmettre des valeurs 
quantifies a travers la pile protocolaire. Le probleme de la transparence 
20 devient celui de la transmission de plusieurs entries binaires (typiquement la 
quantification peut etre faite sur 4 ou 5 bits) au lieu d'une entree binaire 
unique pour chaque bit d'information considere, Toutefois, comme la 
transmission ne se fait pas directement mais a travers un r6seau, les bits 
d'information qui interessent Tapplication constitue seulement une partie 
25 formant la partie utile de la sequence effectivement 6mise. Comme il est 
illustre a la figure 3, cette sequence emise est composee des donnees utiles 
encadr6es par des en-tetes et eventuellement des terminaisons de paquet 
(par exemple des champs de controle tels que les codes cycliques de 
rendondance CRC). 

30 De fagon plus explicite, la transmission de donnees dans le sens 

descendant (du niveau applicatif au niveau acces reseau) a travers la pile 
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protocolaire consistera a chaque transition de couches dans I'execution des 
etapes suivantes [1] : 

• Obtenir la sequence de donnees S L+1 de la couche superieure, 

• Generer I'en-tete ad hoc et eventuellement des champs de controle 

• Construire la nouvelle sequence de donnees S L en concatenant I'en-tete 
la sequence S u+1 et le champ de controle. Cette etape est eventuellement 
real.see en decoupant la sequence de donnees en plusieurs blocs ceci 
en tenant compte des limitations eventuelles de taille imposees par le 
protocole. Dans ce dernier cas, les paquets resultants peuvent avoir un 
nombre d'en-tete inferieur mais gardent une constitution similaire. Leur 
evolution est done semblable a celle des paquets non divises. 

De I'autre cote du canal, la transmission montante a travers la pile 
protocolaire consistera a chaque transition de couches a : 

• Obtenir la sequence de donnees S» w de la couche inferieure, decapsuler 
I'en-tete ad hoc (et eventuellement la terminaison de paquet) pour creer 
la sequence S' L . Cette etape est eventuellement realisee en meme temps 
que les requetes de retransmission dans le cas ou la decapsulation 
montre que le flux de donnees etait corrompu, 

• Envoyer la sequence de donnees S' L a la couche superieure si le champ 
de controle est correct. *" 

Solutions pour echanger I'iniformation a travers les couches de la pile 
protocolaire 

Pour echanger de ('information entre les couches sans modifier la 
p.le protocolaire, une premiere idee serait de contourner la pile et d'utiliser un 
Hen parallels en particulier lorsque Ton travaille sur la meme machine 
Certains liens existent en pratique sur un ordinateur entre les couches de 
bas niveau (noyau) et le niveau utilisateur sans passer a travers la pile 
protocolaire. Par exemple, il est possible d'utiliser des drivers dedies avec 
des liens iotel [3] ou des moyens specifiques, par exemple des moyens de 
selection par la methode BPF (Berkeley Packet Filter [4]) qui permettent a .a 
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couche applicative de capturer et de filtrer les donnees au niveau des 
liaisons de donnees. 

Toutefois, de telles solutions sont applicables uniquement localement (sur 
une meme machine) et correspondent & un cas ou les donnees ne doivent 
5 pas traverser la pile protocolaire. Elles ne s'appliquent done pas dans le cas 
ou le niveau acc£s au reseau et le niveau application ne peuvent pas etre 
connectes de cette fa9on. 

Une autre solution proposee permet I'echange d'information telle que la 
fiabilite ou information souple k travers un reseau entre le decodeur de 
10 source et le decodeur de canal, en 6vitant toute interference avec I'utilisation 
standard du reseau et en consequence, en 6vitant de red^finir des 
protocoles existants. Presentee dans la reference [5], cette solution de 
« transparence pour le reseau » repose sur la presence de couches 
adaptatives qui permettent de prendre en compte les mecanismes existants 
15 de qualite de service QoS, et sur la validation du concept dans un 
environnement Berkeley Software Distribution Linux. Une telle solution a 
I'avantage de pouvoir s'adapter a toute pile protocolaire et a tout reseau. EHe 
impose toutefois de poss6der une connaissance parfaite de la pile 
protocolaire au niveau de Tacces r§seau et de ('application. Elle est de plus 
20 assez complexe car elle oblige & decapsuler une fois de plus au niveau de la 
couche physique pour modifier la donnee transmise. 

Ces solutions presentent comme inconvenient majeur de 
necessiter un m^canisme capable de construire ou de modifier le contenu 
des paquets IP valables au niveau physique et au niveau acc6s reseau. 
25 Compression d'en-tete 

Les liaisons ou communications sans fils sont caracterisees par 
une largeur de bande limitee qui, en pratique, limite le debit d'informations 
emises ou regues par un utilisateur. Une telle liaison est vue 
traditionnellement comme un goulot d'etranglement (particulierement pour 
30 des taux d'erreur binaire BER et de trame FER entre 10' 2 et 10" 5 ) pour la 
transmission de donnees car elles conduisent souvent k des retransmissions 



I Ol UCfJUl 



6 



multiples des donnees, qui aggravent le probleme de I'etroitesse de la bande 



limitee 



En consequence, la transmission directe des paquets IP sur des liens 
Physiques sans fil conduit a un gaspillage important du debit d'information 
b,naire utile, car en fait les en-tetes des couches RTP, UDP et IP ajoutent 
une charge non negligeable aux donnees utiles. Cette charge peut etre 
a,sement reduite car ces en-tetes sent souvent redondantes, soil a Pinterieur 
de len-tete elle-meme ou avec les en-tetes precedents ou suivants te 
paquet, Dans un contexte de donnees temps-reel, ou les paquets doiven, 
etre transmis rapidement, les charges resultant de I'en-tete peuvent atteindre 
lusqu a plusieurs fois la taille des donnees utiles (jusqu'a un facteur d'environ 
3). Par ailleurs les meoanismes de correction d'erreurs (Forward Error 
Correction ou FEC) appliques a la couche de liaison de donnees MAC son, 
generalement choisie pour garantir un faible taux d'erreurs, ceci pour assurer 
que les paquets IP ne seront pas rejetes lorsque leur CRC es, verifie dans la 
couche 3 (IP), ceci conduit a une protection globale du paque, IP au niveau 
le plus eleve, lorsqu'en fait seul I'en-tete est particulierement sensible aux 
erreurs. Pourtant, les donnees multimedia transmises peuvent souvent 
tolerer un taux d'erreur plus eleve grace aux divers meoanismes de 
conection applique* aux oodeurs de source (robustesse du decodage 
techniques de masquage,..). - 

Pour repondre au double objectif de la reduction d'en-tete et de 
augmentation de la robustesse de I'en-tete pour les liaisons sans fi. un 
nouveau protocols propose par I'lETF a ete introduit dans les versions 5 et 6 
de I'UMTS par le groupe de travail 3GPP. Ce schema, designe sous 
I expression .Compression d'en-tete robuste » (Robust Header 
Compression ou ROHC) a ete standardise par I'lETF sous la reference RFC 
3095(6]. Le principe du mecanisme ROHC est presente a la figure 4 La 
standardisation de la compression d'en-tete RTP/UDP/IP pour les liaisons 
UMTS est en cours d'§tude par I'lETF [7]. 
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La figure 5 permet de mieux illustrer le mecanisme de ROHC. Les 
champs d'en-tete variables IP, UDP, RTP au niveau de la pile protocolaire 
peuvent etre classifies comme suit : 

INFERRED (d^crites) : donnees qui peuvent etre directement d^rivees des 
5 autres champs d'en-tete. Elles ne sont pas transmtses, 

STATIC: champs statiques pour Pensemble de transmission de donn6es. lis 
sont transmis une seule fois. 

STATIC-DEF : champs d<§finissant le flux de donnees. lis sont geres comme 
la classification STATIC. 
10 STATIC-KNOWN: champs avec des valeurs connues. lis ne sont pas 
transmis. 

CHANGING : champs dont les valeurs changent regulierement, soit de 
maniere aleatoire, soit periodiquement. Us sont transmis en totalite. 
II est ainsi facile de comprendre que le taux de compression obtenu est 
15 assez important et permet d'economiser une « grande » largeur de bande de 
transmission. Cette largeur de bande disponible peut etre utilisee pour mieux 
proteger les en-tetes extremement fragiles, Pensemble des donnees ou ; 
encore transmettre plus d'information. 

20 Uinvention propose notamment une solution permettaht l'6change 

d'informations (CSI, SSI, DRI, SAI .) entre le decodeur de source et le 

d6codeur de canal en presence de couches reseaux interm§diaires sans 
modification de ces couches. II est alors possible d'utiliser les informations 
6changees pour ameliorer la performance de deeodage, par exemple en 

25 realisant un deeodage souple grace aux informations de fiabilite (DRI, SAI). 

Dans la suite de la description, on designe par « sens 
descendant » la transmission d'informations allant de la couche applicative 
vers la couche acc&s reseau et par « sens montant » la transmission 
deformations de la couche acces reseau vers la couche applicative. 

30 Uinvention concerne un precede pour echanger des donnees 

entre deux couches d'une pile reseau dans un systdme de transmission de 



8 



donnees comprenant un mecanisme de compression et de decompression 
d'en-tete. II est caracterise en ce qu'il comporte au moins les etapes 
suivantes : 

• transmettre | es paquets initlaux a une etape de 
compression/decompression d'en-tete des paquets, et slmultanement 

• transmettre des informations supplementaires a une etape de mise en 
forme pour produire/extraire lesdites informations dans des paquets 
supplementaires compatibles avec la pile reseau. 

La transmission des informations circulant du niveau acces reseau 
vers le niveau applicatif, comporte par exemple au moins les etapes 
suivantes : 

• differencier les informations provenant du canal de transmission ou du 
decodeur de canal en un flux de paquets initiaux et un flux d'informations 
supplementaires prealablement quantifies, 

• transmettre les paquets initiaux codes et les informations 
supplementaires a une etape de decompression d'en-tete, 

o mettre en forme les informations supplementaires quantifies en fonction 
des caracteristiques de la pile protocolaire, 

• transmettre les deux flux ainsi obtenus a une etape de codage de source 
ou a une etape de decodage de source. 

Lsi Emission ^informations circulant du niveau applicatif vers 
le n,veau acces reseau, le precede peut comporter au moins les etapes 
suivantes : 

• differencier les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux et un flux de paquets 
d'informations supplementaires, 

• compresser les en-tetes des paquets initiaux et les transmettre a une 
etape de codage de canal, 

- mettre en forme les informations supplementaires par extraction de 
('information supplemental pour transmission a I'etape de codage canal, 



9 transmettre le flux genere par le codage de canal pour Emission vers le 
canal de transmission. 

La transmission ^informations circulant du niveau applicatif vers 
le niveau acc6s reseau, le procede comporte par exemple au moins les 
etapes suivantes : 

® differencier les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux et un flux de paquets 
d'informations supplementaires, 

• compresser les en-tetes des paquets initiaux et les transmettre & une 
6tape de codage de canal de la couche d'acces, 

» mettre en forme les informations supplementaires par extraction de 
Tinformation supplemental pour transmission a Petape de decodage 
canal, 

• transmettre le flux gen6r6 par le codage de canal pour remission sur le 
canal de transmission. 

La transmission d'informations circulant du niveau applicatif vers 
le niveau acces reseau, il peut comporter au moins les etapes suivantes : 

• differencier les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux et un flux de paquets 
d'informations supplementaires, 

• compresser les en-tetes des paquets initiaux et les transmettre a une 
etape de codage de canal, 

• mettre en forme les paquets transportant les informations 
supplementaires quantifies par compression d'en-tete en fonction des 
caracteristiques de la pile protocolaire pour transmission a Petape de 
codage canal, 1 

• transmettre les flux generes par le codage de canal pour emission sur le 
canal de transmission. 

La presente invention pr6sente notamment les avantages 

suivants : 
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« Elle est compatible avec Ies reseaux existants IP qui implemented le 
processus de compression d'en-tete. Elle permet de transmettre des 
informations supplementaires via le mecanisme de compression et de 
reconstruction d'en-tete en contrepartie d'une augmentation reduite de la 
complexity numerique. 

• Elle peut etre appliquee tout en utilisant Ies outils de qualite de service 
proposes par IETF pour la pile protocolaire OSI. 

• Elle permet de beneficier de la connaissance des elements disponibles 
au niveau de couches donnees de la pile protocolaire, ces elements 
n'etant habituellement pas transmis. 

• Elle permet notamment : 

• de transmettre des informations supplemental telles que la fiabilite 
des bits decodes, Information sur I'etat du canal ou de la source 
(statistiques, etc) tout en restant compatible avec Ies 
recommandations OSI, 

• de localiser ('information necessaire pour generer des en-tetes de 
paquets valables supplementaires et eventuellement de modifier Ies 
en-tetes des paquets initiaux selon Ies besoins de I'utilisateur au 
niveau acces reseau, 

• d'extraire ('information supplemental a la couche d'acces reseau et 
de I'utiliser comme donnee utile pour Ies paquets supplementaires 
valides transmis par un port dedie a un niveau d'application. 

D'autres avantages et caracteristiques de la presente invention 
apparattront mieux a la lecture de la description qui suit donnee a titre 
Ulustratif et nullement limitatif annexee des figures qui represented : 
« La figure 1 un schema generique de decodage source canal conjoint, 

• La figure 2 un decodage conjoint source canal sur un reseau, 

• La figure 3 un principe de syntaxe pour un paquet genere'par une pile 
protocolaire, 
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• La figure 4 le principe du mecanisme ROHC, 

o La figure 5 un exemple de classification des champs d'en-tete pour une 
pile RTP/UDP/IPV4, 

• Les figures 6A et 6B un schema des transmissions d'information du cote 
5 emetteur, 

» Les figures 7A et 7B un schema des transmissions d'information du cote 
recepteur, 

• Les figures 8A et 8B, les ^changes d'information de l'6metteur vers le 
recepteur, 

10 • Les figures 9A et 9B, les ^changes d'information du recepteur vers 
Pemetteur dans le cas de I'existence d'un canal de retour ou pour une 
transmission bi-directionnelle, 

• La figure 10, le traitement des informations au niveau du module de 
compression/decompression, 

15 • La figure 11 un exemple de generation de champs d'en-tete pour des 
paquets supplementaires dans une pile RTP/UDP/IPv4, 

• La figure 12 un exemple de classification de champs d'en-tete pour des 
paquets originaux dans une pile RTP/UDP/IPv4, 

• Les figures 13 et 14 deux exemples d'extraction d'informations 
20 supplementaires, 

• La figure 15 un exemple ^application de I'invention dans un contexte de 
transmission sans f il avec compression d'en-tete. 

En resume, ('information supplemental transmise du niveau 
25 acces reseau au niveau application est placee daps des paquets valides 
generes par le module de compression d'en-tete en paralieie k la 
transmission des donn6es d'origine. Cette integration au sein du processus 
de reconstruction suppose que la syntaxe a utiliser pour construire des 
paquets supplementaires est connue et que la syntaxe des paquets des 
30 donn6es d'origine reconstruits peut etre modifiee en fonction du souhait de 
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rut,l,sateur. De maniere similaire, Information supplemental a transmettre 
du n,veau applicatif au niveau acces reseau est transmise via des paquets 
supplementaires qui son t intercepts par le module de 
compression/decompression d'en-tete et qui sont extraits pour etre utilises 
selon les besoins des utilisateurs. 

Le module de compression/decompression 7 est un module 
adapte a mettre en ceuvre un mode de compression d'en-tete et un mode de 
decompression, selon le sens de transmission des informations. Danse sens 
montant, le module de compression/decompression fonctionne en mode 
decompression a.ors que dans le sens descendant, il fonctionne en mode de 
compression. 

Us fi 9 ures 6A et <® dScrivent un exemple d'echanges 
existent* du cate emetteur E de la transmission ayant la capacite de 
transmettre des informations supplementaires. 

(-'architecture de I'emetteur E est similaire a celle decrite a la 
figure 4, ou le codeur de source 1 est en liaison avec una partie comprenant 
un module 7 de compression/decompression d'en-tete et un codeur 
2/decodeur 3 de canal par fintermediaire d'une pile protocoled 6 
comprenant plusieurs couches reseau (I....K,. Dan s le cas (classique) oO II 
exrste una voie de retour ou lorsque la transmission est bWlrectionnelle la 
couche acces du cote emetteur comports egaiement un decodeur 3 de canal 
lu, permettant de recevoir et de decoder les informations de retour, aussi 
appelees observations du canal. 

La figure 6A schematise les echanges dans le sens « montant » 
de la couche acces reseau vers la couche applicative. Le module de 
compression/decompression 7 fonctionne en mode decompression Les 
observations en provenance du canal 5 sont transmises au decodeur de 
canal 3 qui generent un paquet de donnees d'origine estimees P esl et un flux 
deformations supplementaires quantifiees Supq selon des techniques dont 
un exemple est donne a litre illustratif et nullement limitatif. Ces deux flux 
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sont transmis au module de compression/decompression 7 d'en-tete qui 
applique un traitement standard aux paquets de donn6es d'origine et qui 
transforme reformation supplementaire en paquets supplementaires 
compatibles avec les protocoles transmis aux couches. 
5 Les informations supplementaires contenues dans les paquets sont ensuite 
utilises par exemple pour determiner les parametres du codeur de source 
en fonction de Tetat du canal (CSI). 

La figure 6B schematise les ^changes existants dans le sens 
descendant entre le niveau applicatif et le niveau acces reseau. 
10 Les paquets initiaux et les paquets contenant des informations 
supplementaires quantifies au niveau du codeur de source 1 sont transmis 
au module 7 de compression d'en-tete qui les differencie par exemple au 
moyen d'un champ d'en-tete particulier (par exemple le numero de port 
UDP). Ce dernier comprime les en^tetes des paquets initiaux. II recupere les, 
15 informations quantifies. Les deux flux ainsi generes sont transmis au codeur 
de canal 2 qui les differencie. 

Selon la valeur fixee du champ d'en-tete en fonction des besoins 
de I'utilisateur, le module de compression d'en-tete recupere les informations 
supplementaires quantifies par extraction des paquets differencies pour les 
20 transmettre directement au codeur de canal, de fagon synchrone ou non 
synchrone avec les paquets initiaux. En effet, dans le cas ou Tinformation 
suppimentaire (par exemple SSI) n'est pas directement Ii6e a des paquets 
initiaux donnes, ceux-ci peuvent etre absents et seule de reformation 
supplementaire transmise. Le codeur de canal d6quantifie ces informations 
25 et les utilise alors (par exemple la SSI qui peut permettre de faire de la 
protection inegale des donn6es (Unequal Error Protection ou UEP)). 

Dans le cas ou les informations supplementaires sont detectees 
comme etant destinees au decodeur de canal 3 du recepteur, les paquets 
contenant Tinformation supplementaire ont leurs en-tetes compressees par le 
30 module de compression d'en-tete et transmis au codeur de canal 2 pour 
codage et emission sur le canal 5. Les trames emises sont alors regues et 
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decodees au recepteur et remontent au niveau du module de 
compression/decompression 7 du recepteur qui reconnaitra les paquets 
destines au decodeur de canal et les lui transmettra. 

Les figures 7A et 7B represented les echanges d'information qui 
se deroulent du cote du recepteur. ^architecture de ce recepteur est 
semblable a celle du recepteur de la figure 4. 

La figure 7A schematise les echanges dans le sens « montant » 
de la couche acces reseau vers la couche applicative. Les observations sont 
recues par le decodeur de canal 3 qui genere les donnees estimees d'origine 
(donnees utiles estimees) et des informations supplemental quantifies 
(par exemple SAI, DRI, ..) selon des methodes dont un exemple est detaille 
c-apres. Ces deux flux sont transmis au module de compression d'en-tete 7 
qu. genere des paquets contenant des donnees d'origine reconstruites et des 
paquets contenant des informations supplemental. Ces informations etant 
generees typiquement par quantification des informations souples en sortie 
du decodeur 3. 

La figure 7B schematise les echanges d'information dans le sens 
descendant de la couche applicative vers la couche acces reseau Les 
paquets contenant les donnees utiles et les paquets contenant les 
informations supplemental sont transmis au module de compression d'en- 
tete 7 qui genere des paquets de donnees utiles avec eh-tete compressees 
et les transmet au codeur de canal 2 pour emission sur le canal 5 (dans le 
cas ou un canal de retour existe ou lorsque la transmission est bi- 
directionnelle) ainsi que les informations supplemental quantifies qui 
peuvent etre destinees soit au decodeur de canal 3 soit au codeur de canal 2 
s'il existe. 

Les differents mecanismes decrits aux figures 6A et 6B 
s'appliquent respectivement pour les figures 7A et 7B. 
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Les figures 8A et 8B repr6sentent les echanges d'information qui 
se cteroulent de Pemetteur vers le recepteur. Uarchitecture de ce recepteur 
est semblable a celle du recepteur de la figure 4. 

La figure 8A schematise les ^changes d'information dans le sens 
5 descendant de la couche applicative vers la couche acces reseau. Les 
paquets contenant les donnees utiles et les paquets contenant les 
informations supplementaires sont transmis au module de compression d'en- 
tete 7. Celui-ci differencie les paquets supplementaires et les trouvant 
destines au recepteur leur applique le m§me traitement que les paquets de 
10 donnees initiates : en sortie du module de compression d'en-tete 7, on 
obtient done un flux indifferencie a Tentr6e du codeur de canal 2, qui va les 
coder et les transmettre sur le canal 5. ^interpretation des donnees 
supplementaires est detailtee en Figure 10. 

La figure 8B schematise les echanges d'information dans le sens 
1 5 montant de la couche acces reseau vers la couche applicative. On suppose 
ici la presence d'un canal de retour ou une transmission bi-directionnelle, 
done la presence d'un decodeur de canal a Tdmetteur. Les observations 
faites sur le canal sont fournies au decodeur de canal 3 qui les fournit au 
module de decompression. Ce decodeur est 6galement en mesure de fournir 
20 de Information supplemental quantifiee (ex. CSI) au module de 
decompression 7. Le module de decompression 7 traite alors les diff§rents 
flux regus. II les differentie et reconstruit les paquets originaux mais 
6galement il g£nere le cas echeant des paquets supplementaires, dont les 
erv t§tes seront compress^es par le module de compression avant 
25 reemission sur le canal vers le recepteur par le codeur de canal 2. 

Les figures 9A et 9B representerit les ^changes d'information qui 
se dSroulent du recepteur vers I'emetteur dans le cas ou un canal de retour 
existe ou pour une transmission bi-directionnelle. Uarchitecture de ce 
30 recepteur est semblable k celle du recepteur de la figure 4. 
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Les differents mecanismes dscrits aux figures 8A et 8B 
s'appliquent respectivement aux figures 9A et 9B. 

La figure 10 represente le traitement des informations 
supplemental au niveau du module de compression/decompression Ce 
fragment est slmilaire pour I'emetteur ou pour le reoepteur. La difference 
etant est le module applioatif vise : codeur de source 1 ou decodeur de 
source 2. Le flux de donnees indifferencie en provenance du canal 5 est 
receptlonne et decode par le decodeur de canal 3 et transmis au module 7 
de decompression d'en-tete. Celui-ci different les paquets, reoonstrui. tes 
paquets originaux de donnees et selon les cas, fransmet fee informations 
supplementaires (ex: parametres de codage) au codeur de canal 2 ou au 
decodeur de canal- 3 ou genere des paquets supplemental cbnteriant 
I information supplements pour la remontee vers la couche application 

Dtfferentes methodes pour generer les en-tetes, pour modifier les 
paquets de donnees, pour utiliser .Information supplemental, pour 
quantifier les informations supplementaires sent explicitees ci-apres 
Generation des paquets supplementaires au niveau applicatlf et 
extraction des paquets supplementaires au niveau acefcs reseau. 

Le precede selon invention permet de transmettre ('information 
suppiementaire du niveau applicatif au niveau accSs mseau. En particulier 
(fours 2) les informations SSI ou SAI peuvent etre explores au niveau 
acces reseau. Pour des systemes utilisant la compression d'en-tete, ceci est 
realises en generant au niveau applicaUf des paquets supplementaires 
contenant Information suppKmentaire. Ces paquets peuvent ensuite etre 
transmis via un numero de port dedie. Ces paquets seront transmis sans 
capacite ARQ (automatic repeat request), comme ils ne seront pas vraiment 
transmis mais intercepts au niveau acces reseau. Au niveau acces reseau le 
module de compression d'en-tete qui tradiUonnellement effectue'la 
compression d'en-tete e, en consequence a une connaissance de la 
structure des paquets, est modifie pour tester la presence du port dedie • 
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• si la presence du port dedie est trouvee, le module reconnaTt le paquet 
supplemental comme tel et I'elimine du flux de donnees. La partie utile 
des donnees est ensuite extraite pour etre utilisee par le decodeur de 
canal (d^modulateur, ..) 
5 • si le port n'est pas un port dedie, le mecanisme classique est applique. 

Generation d'en-tete de paquets valides pour transmettre I'information 
au niveau applicatif 

Le mecanisme de compression d'en-tete repose sur le fait que les 
o champs d'en-tete variables IP, UDP, RTP dans la pile protocolaire ont une 
syntaxe fixee qui peut etre facilement reconstruite a partir d'une information 
partielle (typiquement les classes STATIC, STATIC-DEF et CHANGING). 

Sur un principe similaire, le mecanisme de reconstruction par le 
module de compression d'en-tete (fonctionnant en mode decomprssion) peut : 
15 aussi, en parallele au flux de donnees initiates, reconstruire des paquets 
supplementaires a partir des memes champs d'en-tete. Le principe, illustre 
ci-apres dans le cas d'IPv4, reste naturellement valable dans le cas d'IPv6. 
La figure 11 montre un exemple d'application de ce principe avec 3 classes;, 
de champs d'en-tete : 
20 RECOPIED (recopie) : correspond aux champs qui sont directement copies 
des paquets de donnees valides. En pratique, ces champs appartiennent 
principalement aux classes STATIC, STATIC-DEF et STATIC-KNOWN mais 
peuvent aussi etre de la classe CHANGING, recopies tels que (par exemple 
I'etiquette temporelle ou timestamp), 
25 INFERRED (deduit): comme dans le proced§ ROHC process, ces champs 
sont derives directement des autres champs d'en-tete, 
SPECIFICALLY DERIVED (calcule specif iquement) : ces champs sont ceux 
qui sont modifies specialement pour permettre la transmission de 
I'information supplemental. En particulier : 
30 • le port de destination qui permettra a I'utilisateur de separer le flux de 
donnees initiates du flux de donnees supplementaires et d'eviter ainsi de 
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perturber le fonctionnement habitual des divers protocoles (RTCP par 
example). II est propose da transporter les donnees Initiates et 
I information supplemental sur deux numeros de port distincts (UDP, 
TCP) ; 

• to checksum (le total de ccntraie UDP, qui depend de .a partie utile des 
donnees. II do., etre recalcule en fonction des nouvelles parties utiles que 
les paquets supplementaires transportent, 

• le numero de sequence qui sera utilise pour identifier la correspondanoe 
entre le paquet d'origine et le paquet supplementaire 

• la partie de donnSe utile qui sera remplacee par .information 
supplementaire a transmettre. 

RECOPIED = (Ver, Hd.L, TdeS, Identification , R, M, L, offset, TTL. Protocol 
Source- Adress, Desfinafion address (IPv4), Source Port (UDP) Ver P i 
CCnt M, P.Type, Timestamp, Identification Source Synchronisation (SSRC)' 
Idenfification Source Contribution 1«, CSRC, .dentification Source 
Contribution last) 

'^ERRED = ( Paquet Length. Checksum (,Pv4), Datagram Length (UDP), 

SPECIALLY DERIVED= (Destination Po rt> checksum Sequence 
number (UDP)} H ce 

Modiflcation des paquets d oHg.ne eh fonctlon des beeo.na de 
I utilisateur 

II est possible pour I'utilisateur de modifier les en-tStes des 
paquets inifiaux. Le precede de reconstruction des en-tetes peu, e.re adapts 
a des besoins specifiques de transmission avec de I'information 
supplementaire. Par exemple, ,e checksum sur ,a partie utile des donnees 
(UDP checksum) peut etre neutralise par exemple en etant mia a zero Dans 
ce cas, una erreur dans ia partie utiie des donnees ne conduira pas a une 
«l,m,na.ion de oe paquet dont ,a partie utile peu. etre corrigee grace au 
decodage souple de source. 
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La figure 12 donne un exemple de modification de la classification 
des en-t§tes des paquets pour les paquets originaux dans la pile 
RTP/UDP/IPv4. Les caracteres gras, italique, soulignes, majuscule ou 
minuscule sont respectes entre la figure et la description. 
INFERRED = { Paquet Length, Checksum (IPv4), Datagram Length (UDP)} 
STATIC = { Ver, M, L, Protocol (IPv4), P, E (UDP)} 

STATIC-DEF = {Source Address, Destination address, Source Port, 
Destination Port, Identification Source Synchronisation (SSRC)} 
STATIC-KNOWN = / Hd.L.. R L. Offset Ver} 

CHANGING=fTdeS. Identification, 7TL, CCnt.M. P.tvoe, Sequence Number. 
Timestamo. identification Source Contribution 1st CSRC. Identification 
Source Contribution Oast),} 
SPECIFICALLY DERIVED^ (checksum (UDPtt 

De telles modifications ne perturberont pas la transmission de 
rinformation : le paquet d'origine est transmis normalement a travers la pile 
protocoiaire. Si aucun protocole d'en-tete ne comporte d'erreurs, le paquet 
traverse Fensemble de la pile protocoiaire et est regu au niveau applicatif. 
Les paquets RTCP sont ainsi transmis normalement et la quality de service 
(QoS) de la transmission est garantie. 

Extraction de rinformation presente au niveau acces reseau et 
integration de cette information dans les paquets supplementaires 
valides pour une utilisation au niveau applicatif 

Plusieurs cas peuvent §tre envisages pour transmettre 
rinformation supplementaire, CSI, DRI. Cette information est formatee pour 
etre inseree dans les paquets supplementaires. Ces paquets transportant 
des unites binaires (bits), rinformation doit etre en consequence etre 
transforms en bits. 
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Dans le cas de ('information de fiabilite du decodeur ou de toute 
information directement proportionnelle aux donnees utiles, on utilise une 
etape de quantification [2] applique a un nombre donne k de bits, comme II 
est .llustre a la figure 13 . information b=(b1, b2, ..bn) reelle est quantifiee 

pour obtenir c=( Cll , ... Cnk ) avec bi s ( C|1 , c i2> Cik ). Les ooefficients ci sont 

des elements binaires. 

Dans le cas d'une information relative a I'etat de canal, ou pour 
toute information de tai.le non proportionne.le aux donnees utiles (et en 
prat,que assez courte), ceci implique un precede de quantification ou de 
moderation sur un nombre k de bits donnes, comme il est illustre a la figure 
14. information supplemental est quantifiee selon un modele 

prea.ab.ement defini par I'utilisateur. La sequence d = (c 1( c 2 , Ck ) ou ci e 

{Or -1} est- un element binaire.-represenfe done" Mat du" canal ou toute" 
information semblable. 

De meme, en sortie du codeur/decodeur de source ou 
codeur/decodeur de cana., un quantificateur est dispose pour generer 
I information quantifiee de DRI ou de SSI. 

Cette extraction d'information realisee, les valeurs quantifiees sont 
transmises en parallele au flux standard au module de compression d'en-tete 
qui les exploitera. 

DEWlrE 3 ^" 8 ^ OSS ^'^ Pow" les champs intitules 'SPECIFICALLY 

Les champs presentes ci-dessus comme etant specialement 
denves sont destines a permettre le precede de transmission d'information 
supplementaire. Quelques exemp.es sont donnes a titre illustrate et 
nullement limitatif : 

• le port de destination peut etre choisl soil de maniere dynamique, par 
example comme le premier port directement dlsponible au-deasus du 
port habituellement utilise ou encore fitra enregistre comme un port dedia 
pour une telle transmission, (I'enregistrement des ports dedWs definie par 
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I'organisation IANA que Ton peut trouver a I'adresse internet 
http://www.iana.org) . 

o le numero de sequence. Ce numero peut etre ensuite utilise pour 
identifier les paquets initiaux des paquets supplementaires, 

» la partie des donnees utiles peuvent etre derivees comme il a ete detaille 
precedemment en quantifiant I'information supplementaire. Pour 
I'information de fiabilite, le nombre k peut etre pris egal a 4 ou 5. Le 
premier bit de quantification est par exemple pris egal a la valeur hard 
(estimation de la donnee d'origine) pour une meilleure efficacite. Pour une 
information supplementaire, telle que SSI ou CSl, le format devrait etre 
determine de maniere specifique entre les deux codeurs. Par exemple, 
I'information CSl pourrait etre codee sur 4 niveaux, tres mauvais, 
mauvais, bon, tres bon, ceci correspondant a 2 bits d'information. 

Applications possibles 

Le procede selon I'invention s'applique par exemple pour des 
reseaux a tres faible debit et a bande limitee. Par exemple il est utilise pour 
des transmissions sans fil construites sur un reseau a pile protocolaire avep 
compression d'en-tete tel que un reseau IP/UDP/RTP implementant le 
mecanisme ROHC. 

II s'applique aussi dans des reseaux avec un temps de 
retransmission aller retour (Return Time Trip ou RTT) ou I'utilisation de 
I'information CSl peut aider le comportement du decodeur de source pour 
choisir entre la retransmission demand^e ou I'application des techniques 
d'annulation ou encore d'autres traitements des donnees recues, ceci en 
fonction de la probability de chance de receyoir correctement 1'information a 
la seconde demande. 

Ce procede peut aussi presenter des avantages lorsque 
I'information sur le flux d'information en provenance de la source tel que 
I'information SSI peut etre fournie par le codeur de source au decodeur du 
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canal. Ceci est par exemple le cas lorsque la protection d'erreur inhale 
(UEP) est realisee au niveau acces reseau. 

La figure 15 reprfeente un exemple de mise en ceuvre de 
invention dans un contexte combine transmission par fil/transmission sans 
f.l ou information supplemental peut etre utilises par exemple entre 
cheque utilisateur et son point d'entree, chacun etant separe de I'autre par 
un canal de transmission de fiabilite faible. 
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REVEND1CATIONS 

1 - Procede pour echanger des donnees entre deux couches d'une pile 
reseau dans un systeme de transmission de donn6es comprenant un 
nricanisme de compression et/ou de decompression d'en-tete, caract6rise 
en ce qu'il comporte au moins les 6tapes suivantes : 

• transmettre les paquets initiaux a une etape de 
compression/decompression d'en-tete des paquets, et simultan£ment 

• transmettre des informations supplementaires a une etape de mise en 
forme pour produire lesdites informations dans des paquets 
supplementaires compatibles avec la pile reseau. 

2 - Procede selon la revendication 1 caracterise en ce que la transmission 
des informations circulant du niveau acces reseau vers le niveau appliciatif, 
comporte au moins les etapes suivantes : 

• differencier les informations provenant du canal de transmission ou, du 
d6codeur de canal en un flux de paquets initiaux et un flux d'informations 
supplemental res pr6alablement quantifies, 

20 • transmettre les paquets initiaux codes et les informations 
supplementaires a une etape de decompression d'en-tete, 

• mettre en forme les informations supplementaires quantifies en fonction 
des caracteristiques de la pile protocolaire, 

• transmettre les deux flux ainsi obtenus a une etape de codage source. 

25 

3 - Proc6de selon la revendication 1 caracteris§ en ce que la transmission 
des informations circulant du niveau accds reseau vers le niveau applicatif, 
comporte au moins les etapes suivantes : 

• differencier les informations provenant du canal de transmission ou du 
30 d^codeur de canal en un flux de paquets initiaux et un flux d'informations 

supplementaires pr6alablement quantifies, 



24 



• transmettre le8 paquets initiaux codes e. ,es informations 
supplSmentaires a una etape de decompression d'en-tete 

• mettre en forme les informations supplemental quantifies en fonotion 
des caracteristiques de la pile protooolaire, 

• transmettre les deux flux ainsi obtenus a una etape de deoodage source. 

o'inJrr Se ' 0n ' a 1 - - *» '* fransmission 

dtnformatrons crculant du niveau applicatlf vers le niveau acces reseau II 
comporte au moins les Stapes suivantes : 

• difference les paquets provenant de la pile protooolaire en un flux de 
paquets initiaux et un flux de paquets informations supplemental 

• oompresser les en-,e,es des paquets initiaux e, les transmettre a'une 
etape^de codage decariar, ' """ - ■ - 

• mettre en forme les informatlons supplemema|res pgr 

I tnformation supplemental pour transmission a Petape de codage canal 

• transmettre ,e „ux genera par ,e codage de cana, pour emission vers ,e 
canal de transmission. 

liJZT Se ' 0n T reVendiCa,ton 1 «~«*« - - *» ,a transmission 
d,nforma„ons cmulan. du niveau applicatif vers ,e niveau acces reseau » 

comporte' au moins les efapes suivantes ': ~ ' 

• differencier les paquets provenant de la pile protooolaire en un flux de 
paquets initiaux e. un flux de paquets informations supplemental 

• oompresser les en-tetes des paquets Initiaux e, les transmettre a'une 
etape de codage de canal de la couche d'acces 

• mettre en forme les informations supplemental par extraction de 
linformatton supplemental pour transmission a I'atape de decodage 
canal, 

. transmettre ,e flux genere par le codage de cana, pour remission sur ,e 
canal de transmission. 
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6 - Procede selon la revendication 1 caract£ris6 en ce que la transmission 
d'informations circulant du niveau applicatif vers le niveau acces reseau, il 
comporte au moins les §tapes suivantes : 
5 • diff6rencier les paquets provenant de la pile protocolaire en un flux de 

paquets initiaux et un flux de paquets d'informations supplementaires, 
© compresser les en-tetes des paquets initiaux et les transmettre a une 

6tape de codage de canal, 

♦ mettre en forme les paquets transportant les informations 
< 10^)) supplementaires quantifies par compression d'en-tete en fonction des 

caracteristiques de la pile protocolaire pour transmission k Petape de 
codage canal, 

• transmettre les flux gen§res par le codage de canal pour Emission sur le 
canal de transmission. 

15 

7 - Precede selon Tune des revendications 1 a 3 caracteris§ en ce que 
Petape de decompression consiste a differericier les paquets provenant du 
canal de transmission, reconstruire les paquets originaux de donn6es, 
transmettre les informations supplementaires generees au codeur de panal 

20 ou au decodeur de canal. 

8 - Procdde selon Pune des revendications 1 a 3 ou 7 caracteris§ en ce que 
Petape de decompression consiste a differencier les paquets provenant du 
canal de transmission, reconstruire les paquets originaux de donnees, 

25 gen^rer des paquets supplementaires contenant Pinformation supplementaire 
et les transmettre vers le niveau applicatif. 
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